Summary

The integration suites under `packages/{drizzle,protect,stack}` all INSERT into a `protect-ci` table that was previously assumed to exist (originally created by hand on the shared CI Supabase project). On a fresh database — e.g. the new Supabase instance now provisioned for Dependabot CI runs — these suites fail with:

```
PostgresError: relation "protect-ci" does not exist
```

This PR makes the suites self-create their fixture, mirroring the pattern already used in `packages/{protect,stack}/tests/searchable-json-pg.test.ts` for the `protect-ci-jsonb` table.

What changed

Added an idempotent `CREATE TABLE IF NOT EXISTS "protect-ci" (...)` to the `beforeAll` of:

• `packages/drizzle/tests/drizzle.test.ts` — already has a postgres-js connection, so the DDL goes inline.
• `packages/protect/tests/supabase.test.ts` — opens a short-lived postgres-js connection just for the DDL, closes it before tests run via the supabase client.
• `packages/stack/tests/supabase.test.ts` — same pattern as protect/supabase.

The two supabase suites also send `NOTIFY pgrst, 'reload schema'` after the DDL so PostgREST picks up the new table immediately rather than waiting for its polling interval. No-op on plain Postgres.

The two supabase suites now also require `DATABASE_URL` (for the DDL step). The CI workflow already populates it in those packages' `.env` files; local devs running these suites need it set.

Schema

The CREATE TABLE covers the union of every column the three suites read or write:

```sql
CREATE TABLE IF NOT EXISTS "protect-ci" (
id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
email eql_v2_encrypted, -- drizzle suite
age eql_v2_encrypted, -- drizzle + supabase
score eql_v2_encrypted, -- drizzle + supabase
profile eql_v2_encrypted, -- drizzle suite
encrypted eql_v2_encrypted, -- supabase suites
created_at TIMESTAMPTZ DEFAULT NOW(),
test_run_id TEXT
)
```

All encrypted columns are nullable, so each suite only populates the subset it needs.

Out of scope

• The `protect-ci-jsonb` table already self-creates via the searchable-json-pg suites; not touched here.
• Cross-suite consolidation (a shared SQL fixture file) — the per-suite duplication is small and clear; abstraction would mostly add indirection.
• Pre-existing typecheck errors in `encrypt-query-searchable-json.test.ts` and `searchable-json-pg.test.ts` (unrelated to this change).